1. Field of the Invention
The present invention relates to methods and apparatus for MAC-layer timestamping in a wireless sensor platform.
2. Description of the Related Art
The present invention incorporates by reference the following publications:
[1] IEEE Standard for Information technology, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs); and
[2] Time Synchronization Module S/W Detailed Level Design Version 1.1 by Samsung Telecommunications America.
TinyOS-based Wireless Sensor Networks (WSNs) are transitioning to real-world applications (e.g. TinyDB, Arch Rock Primer Pack/IP, Crossbow Wireless Sensor Network), and expected to become more prevalent in our everyday life. The values of WSN reply on their low energy consumption, low cost, easy deployment, and interoperability in large numbers. To achieve these, new devices and new communication stacks are being developed. Recently, a few of vendors have released 8051-based System on a Chip (SoC) sensor motes (e.g TI CC2430/MicrotrollerUnit (MCU) 8051, CC2431/MCU8051), which combines radio and MCU at low cost. Due to the new release, TinyOS community formed a new working group, “TinyOS 8051 Working Group” in March, 2005 and is working on porting NesC and TinyOS to the 8051 microcontroller platform.
To support the interoperability, low cost, and low power consumption requirements, a new IEEE 802.15.4 standard has also been proposed recently. The IEEE 802.15.4 standard defines the physical and medium access layer (MAC) for wireless personal area networks (WPANs). The IEEE 802.15.4 standard is compliant with Zigbee. The ZigBee Alliance—an organization with more than 150 company members—has been working in conjunction with the IEEE Task Group 15.4 in order to specify a full protocol stack for WPANs. So IEEE 802.15.4 is establishing its place on the market as enablers of the pervasive, interoperable wireless sensor networks (WSNs).
The emerging new devices (8051 platform) and new communication stacks (802.15.4) bring new challenges to TinyOS-based WSN, especially for MAC-layer timestamping based time synchronization. The MAC-layer timestamping based time synchronization is both hardware-dependent and MAC/Physical Layer (PHY)-layer dependent. Time synchronization (TS) is a critical piece of infrastructure for WSN. Many applications in WSN need synchronized time (for data fusion, TDMA schedules, synchronized sleep periods, etc.). To meet the high-accuracy synchronization requirement, MAC layer timestamping is needed to eliminate and reduce non-deterministic factors. In MAC-layer timestamping based time synchronization, Time Synchronization module directly time-stamps packets at the MAC/PHY layer, thus the non-determinism of send and/or receive time can be reduced, resulting in high precision performance.
All previous works (e.g. Flooding Time Synchronization Protocol (FTSP) on Mica and Telos) realizes MAC-layer timestamping only on Mica Atmel (AVR) MCU platform and Telos TI MSP430 MCU platform and only through TinyOS default communication stack. The existing approaches for MAC-layer times-stamping are not applicable to the WSN with the new hardware and new 802.15.4 stack. In addition, traditional MAC-layer stamping approaches have been only tested on the application with one single Time Synchronization module, not in a large software system with multiple modules and multiple messaging. The traditional MAC-layer stamping approach is not scalable. In the traditional MAC-layer timestamping approach, Start-of-frame delimiter (SFD) signal events are created for every sent/received message in the interrupt handling context, and are directly given to time synchronization module for further processing. If there are multiple modules in a large software system and multiple messaging (e.g. a lot of broadcast messages), every node may receive/send multiple messages in a very short time and the SFD signal event in the interrupt context will be created for every sent/received message. In this case, the code needed to run in the interrupt handlers will be too large, the interrupts will be lost or queued, which eventually affects the whole system stability and results in node hanging in the worst case.